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REMARKS 

In the Office Action mailed on July 20, 2005, the Examiner: rejected claims 1-21 as 
being directed to non-statutory subject matter; rejected claims 1, 2, 4-15 and 17-21 under 
35 U.S.C. § 103(a) over U.S. Patent No. 6,225,995 to Jacobs et al. ("Jacobs") in view of 
U.S. Patent No. 6,389,467 to Eyal ("Eyal"); and rejected claims 3 and 16 under 35 U.S.C. 
§ 103(a) over Jacobs in view of Eyal and further in view of U.S. Patent No. 6,584,468 to 
Gabriel et al. ("Gabriel"). Applicants herein amend claims 1-3, 5-16 and 18-21, and cancel 
claims 4 and 17. As a result, claims 1-3, 5-16 and 18-21 are pending. Further 
examination and review in view of the amendments and remarks below are respectfully 
requested. 

Applicants' techniques are directed to enhancing the quality of original metadata 
associated with a streaming media file having a Uniform Resource Indicator (URI). Some 
of the techniques enhance the original metadata that is maintained in a database by 
adding additional metadata derived from the contents of the fields in the URI to the original 
metadata in the database. This allows the streaming media file to be searchable under the 
added metadata. 

I. Rejections under 35 U.S.C. § 101 

The Examiner rejected claims 1-21 as being directed to non-statutory subject 
matter. In particular, the Examiner indicated that the "system," "method," and "program 
product" reads on mental construct/abstract idea or, at best, a computer program, per se, 
and "carrier wave" does not clearly define structural elements and are not tangibly 
embodied on a computer readable medium. 

Applicants herein amend claims 1-3 and 5-10 to address the concerns reaised by 
the Examiner. In particular, Applicants amend claim 1 to explicitly recite "A method in a 
computing system." Claims 2, 3 and 5-10 continue to depend from claim 1. Applicants 
herein cancel claim 4, thus making the Examiner's rejection of this claim moot. 
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Applicants herein amend claims 11 and 12 to address the concerns reaised by the 
Examiner. In particular, Applicants amend claim 1 1 to explicitly recite "each of said at least 
one computer includes at least one program stored on a computer-readable medium 
therein." Claim 12 continues to depend from claim 1 1 . 

Applicants herein amend claims 13 and 14 to address the concerns reaised by the 
Examiner. In particular, Applicants amend claim 13 to explicitly recite "A computer- 
readable medium having embodied thereon a program." Claim 14 continues to depend 
from claim 13. 

While Applicants regard each of claims 15, 16 and 18-21 to be directed to statutory 
subject matter in their present form, Applicants herein amend claim 15 to explicitly recite "A 
computer data signal embodied in a carrier wave." Claims 16 and 18-21 continue to 
depend from claim 15. Applicants herein cancel claim 17, thus making the Examiner's 
rejection moot. 

Data signal claims are statutory subject matter if they (1) are manufactured (i.e., not 
a natural phenomenon), (2) are directed to functional descriptive material, and (3) recite a 
practical application or cover a specific manufacture. Data signal claims are approved as 
statutory subject matter by training materials distributed by the USPTO. Training Materials 
for the Computer-Related Invention Guidelines, Tab 1 1 , "Compression/Encryption 
Examples," Example 13. Those materials include the following example claim: 

A computer data signal embodied in a carrier wave comprising: 
a compression source code segment comprising [the code]; and 
an encryption source code segment comprising [the code]. 

This example was later cited favorably in a law review article written by the Solicitor 
of the USPTO, Nancy J. Linck, and co-authored by the Assistant Solicitor of the USPTO, 
Karen A. Buchanan, who participated in the drafting of the above-referenced training 
materials. Patent Protection For Computer-Related Inventions: The Past The Present, 
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And The Future, Hastings Communications And Entertainment Law Journal, VI. 18, No. 4. 
In that article, the above example was recited as an example of a statutory article of 
manufacture claim because it recites a specific manufacture. The article also stated that 
the claim was statutory because it has a practical application in the technological arts in 
that "it can be used to monitor and control the physical processes in an automated 
manufacturing plant." Id. at pp. 677-678. 

Claims 15, 16 and 18-21 recite a generated data signal with the practical application 
of conveying code segments for reorganizing a plurality of fields of a URI, analyzing each 
field of said reorganized fields, identifying metadata associated with said each analyzed 
field, and adding said associated metadata to original metadata in a database. These 
claims recite data signals that (1) do not occur naturally, (2) are directed to functional 
descriptive material, and (3) recite a practical application of allowing the receiver of the 
data signal to use the code segments to improve the quality of the original metadata. 
Therefore, Applicants respectfully submit that claims 15, 16 and 18-21 recite statutory 
subject matter, and respectfully request that this rejection be withdrawn. 

II. Rejections under 35 U.S.C. 5 103 

All of the claims stand rejected over Jacobs in combination with Eyal or Eyal and 
Gabriel. Applicants respectfully traverse this rejection. 

As amended, all of the claims recite (1) analyzing each field of a uniform resource 
indicator (URI) associated with a streaming media file to determine if an association exists 
between each field and predetermined sets of metadata, (2) identifying metadata that is 
associated with each of the analyzed fields, and (3) adding the associated metadata to the 
original metadata in a database, where the original metadata is associated with the 
streaming media file. In rejecting the claims, the Examiner indicated that Jacobs' 
discussion of identifying the metadata associated with a browser request (col. 21, line 40- 
col. 22, line 15, and col. 2, line 65-col. 3, line 20) corresponds to Applicants' analyzing 
each field of a URI associated with a streaming media file to determine if an association 
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exists between each field and predetermined sets of metadata, identifying metadata that is 
associated with each of the analyzed fields, and adding the associated metadata to the 
original metadata in a database, where the original metadata is associated with the 
streaming media file. 

Applicants respectfully disagree. Jacobs does not disclose, suggest or teach (1) 
analyzing each field of a URI associated with a streaming media file to determine if an 
association exists between each field and predetermined sets of metadata, (2) identifying 
metadata that is associated with each of the analyzed fields, and (3) adding the associated 
metadata to the original metadata in a database, where the original metadata is associated 
with the streaming media file. Instead, Jacobs merely describes a mechanism for 
supporting multiple-request operations in a stateless environment. According to Jacobs, 
metadata information is used to identify the transaction type associated with the browser 
request, (col. 23, lines 54-57). In particular, after identifying the metadata, a cartridge 
execution engine uses the URI information to determine the state of the transaction 
associated with the browser request, (col. 23, line 67-col. 24 line 3). With the benefit of 
this state information, the processing of the browser request can resume at the exact point 
at which the previous request stopped, (see col. 3, lines 10-12). 

Jacobs, at col. 2, line 55-col. 3, line 20, recites: 

In a preferred embodiment, processing of a client request is performed as 
follows. The server receives a request from a client, and if the request is for a 
multiple-request operation, the server initiates an operation. Once the operation 
is initiated, the server may either forward the request to another entity (such as 
an application) for processing, or the server may process the request itself. After 
the request is processed, the server assembles a set of state information 
associated with the operation. This state information may include the identity of 
the client, the ID and status of the operation, what has already transpired in the 
operation, and any other context information associated with the operation. 
Once assembled, the state information is incorporated into a URL . This URL, 
along with the response to the client request, is sent back to the client to be 
maintained bv the client . This state information is preferably not persistently 
maintained by the server . 
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When the client submits a second request relating to the same operation, the 
client sends the URL that was previously provided by the server which contains 
the state information. Upon receiving the second request, the server extracts the 
state information from the URL , and uses it to resume the previously initiated 
operation. With the benefit of this state information, the server can resume the 
operation at the exact point at which the previous request stopped. Once the 
operation is resumed, the server either processes the request, or forwards it to 
another entity for processing. After the second request is processed, the server 
updates the state information associated with the operation, and incorporates the 
updated state information into another URL . This URL, along with the response 
to the second request, is sent back to the client to be maintained by the client. 
The client will send this URL in a future request to resume the operation, 
(emphasis added.) 

Jacobs, at col. 21, line 40-col. 22, line 15, recites: 

Each browser request contains URL information that is sent from the sending 
browser in response to a user of the browser selecting a hypertext link on an 
HTML page. The URL information includes a Uniform Resource Indicator (URI) 
portion and a header section. The URI portion includes transaction state 
information and a cartridge name . The transaction state information is used to 
identify the particular state of a multiple-request transaction. The cartridge name 
is used to identify the cartridge type and allows the cartridge execution engine to 
identify the metadata that is associated with the browser reouest . 

The header section is used to store a globally unique transaction ID that is used 
by the database servers to identify the multiple-request transaction that is 
associated with a particular transaction request. 

When a listener receives the browser request, it passes the browser request to 
the dispatcher. The dispatcher then communicates with the virtual path manager 
to determine the cartridge type that is associated with the browser request. In 
one embodiment, the dispatcher forwards the information contained in the URI to 
the virtual path manager. Using the information in the URI, the virtual path 
manager communicates with the configuration provider to determine the cartridge 
type that is associated with the browser message. 

Once the cartridge type is identified, the virtual path manager returns data that 
identifies the cartridge type to the dispatcher. The dispatcher then searches a 
cartridge instance pointer list that includes pointers to cartridge instances that 
have previously been associated with the particular dispatcher. If the dispatcher 
locates a pointer to a cartridge instance that is of the cartridge type that is 
associated with the browser request, the dispatcher uses the pointer to send a 
revised browser message to the cartridge instance. 
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If the dispatcher does not locate a pointer to the type of cartridge instance that is 
associated with the browser request, the dispatcher communicates with the 
resource manager to obtain a cartridge instance of that type. In obtaining the 
cartridge instance, the dispatcher sends a message to the resource manager that 
includes the cartridge type that was previously identified by the virtual path 
manager, (emphasis added.) 

According to Jacobs, the URI portion of the browser request URL includes 
transaction state information and a cartridge name. Of these two URI fields, only the 
cartridge name is used to identify metadata. Moreover, Jacobs' identified metadata is 
associated with the browser request (i.e., the URL). This is in contrast to analyzing each 
field of a URI associated with a streaming media file to determine if an association exists 
between each field and predetermined sets of metadata , as recited. Applicants can find in 
Jacobs no such disclosure or suggestion. 

With regard to adding the associated metadata to the original metadata in a 
database, where the original metadata is associated with the streaming media file, 
Examiner stated in the present Office Action that "the Examiner broadly interprets adding 
associate metadata to original as an updating feature equivalent to (see Jacobs) the 
resource manager updating rows." Applicants respectfully disagree with the Examiner. 
According to Jacobs, if a cartridge is idle for more than a certain amount of time, the 
dispatcher removes a row entry from a status table and sends a message to the resource 
manager that the listener is releasing ownership of the cartridge. In response to the 
message, the resource manager updates a row in its state information table to indicate that 
the cartridge is not owned by any listener and may thus be reassigned to another listener 
or terminated, (described at col. 13, lines 13-67, and shown in Figs. 4 and 5). Thus, in 
Jacobs, the "update" is of a field of a record in a table, where the field indicates ownership 
of the cartridge, and Jacobs updates this field by replacing the prior contents of the field 
with new contents to indicate that the cartridge is not owned by any listener. Stated 
differently, Jacobs' update replaces the old ownership information in the field with the new 
ownership information. This is in direct contrast to adding the associated metadata to 
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original metadata in a database , as recited. Applicants can find in Jacobs no such 
disclosure or suggestion. 

III. Conclusion 

In view of the foregoing, Applicants respectfully submit that claims 1-3, 5-16 and 18- 
21 are allowable and ask that this application be passed to allowance. If the Examiner has 
any questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-8000 

Dated: October 19, 2005 Resp 




Steven D. Lawrenz 

Registration No.: 37,376 
PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 981 1 1 -1 247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorney for Applicant 
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